Method, system and program for credit risk management utilizing credit exposure

ABSTRACT

Software aggregates and integrates credit exposure data across accounting, trading and operational systems within an energy trading organization. A comprehensive model of exposure to all counterparties, across all of their divisions and subsidiaries, is then assembled, enabling the creation of a hierarchical view of each counterparty that models its real-world parent-child relationships, and taking into account netting, setoff, and margin requirements, collateral requirements and contract terms, internal and external views of exposure and liquidity, and risk concentrations based on both system and user-defined risk categories. After aggregating the exposure information, credit, transactions, risk and other properties are determined at any level in the hierarchy and then the system presents a comprehensive, detailed, real-time, enterprise-wide view of current exposure, collateral requirements and outlays for both a company and its counterparties. Walkforward views of potential credit exposure taking into account current and future prices and volumes are also provided.

PRIORITY CLAIM

The application claims the benefit of priority under 35 U.S.C. §119(e)from U.S. Provisional Application No. 60/503,429, entitled, “Method,System and Program for Credit Risk Management Utilizing CreditExposure,” filed on Sep. 16, 2003, and U.S. Provisional Application No.60/503,422, entitled, “Method, System and Program for Credit RiskManagement Utilizing Credit Limits,” filed on Sep. 16, 2003, whichdisclosures are incorporated herein by reference.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to co-pending U.S. patent applicationSer. No. 10/______, (ROME002US1), filed on even date herewith andassigned to the assignee hereof, and incorporated herein by reference inits entirety.

TECHNICAL FIELD

The present invention relates generally to methods, systems and programsfor credit risk management. Still more particularly, the presentinvention relates to methods, systems and programs for credit riskmanagement based on defined relationships and associated creditexposure.

BACKGROUND

Dramatic changes in industry have exposed the need for new processes andtools to measure, analyze and manage credit and liquidity. For example,energy companies have been reeling from corporate scandals, increasedscrutiny and disclosure, and several well-publicized bankruptcies. As aresult, companies are planning for contingent liquidity requirements andmanaging company-wide credit by requiring near-real-time profiles of thecompany's credit exposure and obligations. Some companies do businesswith hundreds of different counterparties and, therefore, have riskassociated with hundreds of different legal entities based on a myriadof different commodities. The data about these counterparties and thetransactions executed with them is spread across many differentspecialized commodity-trading systems.

Unfortunately, the commodity-based nature of enterprise resourceplanning, integration, trading and risk management software currentlyused in most industries revolve around accounts and transactions asopposed to customer relationships or counterparties and their associatedcontracts. This places the relevant data scattered across multiple,disparate systems and forces company executives to manually pulltogether necessary information and resort to spreadsheets andcalculators to obtain the information they need to assess credit riskand make critical decisions regarding their company's credit exposureand obligations. An organization's financial stability depends on atimely, accurate and authoritative picture of credit exposure andliquidity obligations, so it may identify trouble spots, move quickly tomitigate counterparty credit risk, and improve the company's liquidity.This critical information must be made available to organizations bypresenting a comprehensive, detailed, real-time picture of currentexposure and collateral requirements for both the company and itscounterparties. Yet, no current solution provides an effective method totrack and analyze credit exposure and liquidity obligations acrossmultiple systems. In addition to data aggregation limitations, thecurrent offerings do not take advantage of contemporary technologiesthat allow for simplified adaptation of changing functional requirementsand near-real-time processing. Accordingly, it would be desirable toprovide a method, system and program to overcome these problems in theart.

SUMMARY OF THE INVENTION

In accordance with the present invention, improved methods, systems andarticles of manufacture for managing credit exposure are disclosed. Inone preferred embodiment of the present invention, a hierarchical modelof legally associated counterparties and associated transactions with anorganization is created, wherein the hierarchical model includes one ormore counterparty levels containing the legally associatedcounterparties, and one or more master levels containing one or moremaster agreements, each master agreement being between one of thelegally associated counterparties and the organization, and one or moretransaction levels containing one or more transactions, wherein eachmaster agreement provides one or more mechanisms for financialaggregation of associated transactions between one or more of thecounterparties and the organization. Then, aggregate financial exposurefor the organization at each level of the hierarchical model based onthe one or more master agreements and their associated transactions iscalculated. All objects, features, and advantages of the presentinvention will become apparent in the following detailed writtendescription.

BRIEF DESCRIPTION OF DRAWINGS

This invention is described in a preferred embodiment in the followingdescription with reference to the drawings, in which like numbersrepresent the same or similar elements and one or a plurality of suchelements, as follows:

FIG. 1 shows a conceptual diagram of a software architecture in which apreferred embodiment of the prevent invention may be implemented.

FIG. 2 shows a block diagram of a conceptual dataflow diagram of theoperation of the credit exposure application, in accordance with apreferred embodiment of the present invention.

FIG. 3 shows a hierarchical chart representing the organizationalstructure and legal relationships of a parent counterparty and itsaffiliated legal entities, as utilized in a preferred embodiment of thepresent invention.

FIG. 4 shows an example scenario of a credit exposure calculation, inaccordance with the preferred embodiment of the present invention.

FIG. 5 shows a flow diagram of a process implemented by credit exposuremodule 105, in accordance with a preferred embodiment of the presentinvention.

FIG. 6 shows a data flow diagram of calculation stages within thecalculation engine, in accordance with a preferred embodiment of thepresent invention.

FIG. 7 shows a flow diagram of a contractual view using the closeoutsetoff method of the credit exposure calculations, in accordance with apreferred embodiment of the present invention.

FIG. 8 shows a flow diagram of a view of the credit exposurecalculations using a margining method, in accordance with a preferredembodiment of the present invention.

FIG. 9 shows a data table for configuring the exposure components andformulas to be used in calculating credit exposure for counterparties,in accordance with a preferred embodiment of the present invention.

FIG. 10 shows a high-level block diagram of a data processing system 10,which may be a high-level computer system, consistent with an embodimentof the invention with which the method, system and program of thepresent invention may advantageously be utilized.

FIG. 11 shows a screenshot of a web browser page of web-based userinterfaces displaying a summary view of a counterparty's exposure orreverse exposure. The user gets to this page by selecting acounterparty.

FIG. 12 shows a screenshot of a web browser page of web-based userinterfaces displaying exposure/reverse exposure by limit category.

FIG. 13 shows a screenshot of a web browser page of web-based userinterfaces displaying multiple counterparty exposure/reverse exposurewithin the counterparty hierarchy. The page has the following importantcharacteristics.

FIG. 14 shows a screenshot of a web browser page of web-based userinterfaces displaying a summary list of the contracts that have beencreated for the counterparty.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

With reference now to FIG. 1, there is depicted a conceptual diagram ofa software architecture in which a preferred embodiment of the preventinvention may be implemented. The software system 100 comprisesapplication layers or objects, including presentation layer components102, application business services 104, platform services 106 and dataservices 108 connected by a communication link 110. Each of theapplication layers 102-108 communicate with various other businessapplications 112 utilized within a line of business of an enterprise anda database 114 for storage of application data. Line of businessapplications 112 may be accounting software, trading software and otherrisk management applications, for example. Presentation layers 102-108communicate over link 110. Presentation layers 102-108 also communicatewith line-of-business applications 112 and universal database 114 overlink 110 for storing and retrieving data accessed and generated by thesoftware system 100.

Presentation layer components 102 contain a plurality of web-based userinterfaces 103 to provide user display and interface to software system100 and are built on Java Server Page. Application business serviceslayer 104 includes a plurality of software applications to organize,analyze and manage an enterprise's credit risk, the modules includingcounterparty, credit ratings, credit limits, credit exposure andpositions functionality providing various application services.Application business services 104 includes a credit exposure application105 that provides an organization's enterprise view of their current andfuture financial exposure by contract, counterparty and credit limitcategories. Platform services 106 contain service applications toprovide general management of users and security, to issue thresholdsand alerts, and to provide a workflow engine for communicating workflowbetween the various layers 102-108. Layers 104, 106 run on EnterpriseJavaBeans (EJB). Data services 108 contains a message provider anddatabase connection pool applications to provide data services among theother layers 102-106 and between line of business applications 112 anddatabase 114.

With reference now to FIG. 2, there is shown a block diagram of aconceptual dataflow diagram of the operation of the credit exposureapplication 105, in accordance with a preferred embodiment of thepresent invention. The sum total of all transactions 202, sometimescalled deals, entered into by the trading organization or one of itsaffiliated legal entities using software system 100 to determine itsfinancial exposure on deals or contracts (hereinafter the“organization”)is made accessible to credit exposure application 105,for example from database 114 or line of business applications 112.Transactions 202 are a collection of data components on the financialexposure to the organization represented by each of the contractualtransactions 202 entered into by the organization. Billed cash exposurecomponents 204 represent the accounts receivable (AR) resulting from thebilled amounts due from each of the counterparties to the organizationin the transactions 202. Unbilled cash exposure components 206represents each component of the transactions 202 that currently existas a result of the contractual commitments of transactions 202. Forwardexposure components 208 represents mark-to-market (MtM) data on futureexposure represented by transactions 202.

Counterparties, contracts and credit information are collected by creditexposure module 105 to build and store counterparty information block208. This counterparty information 208 represents a database ofinformation regarding the counterparties and contractual relationshipscreated by transactions 202. Counterparty hierarchy 210 provides aplurality of structural models defining interconnected corporateidentities and contractual relationships for each counterparty.Contracts and netting agreements 212 provides a database of contractualagreements with each counterparty and their related rights andobligations comprising the transactions 202.

As will be appreciated, contracts and netting agreements 212 specify thecritical rights and relationships between the parties and can be quitecomplex. This complexity is significantly pronounced in the energyindustry to which the present embodiment has particular application.Most energy traders buy and sell commodities both in a physical sense,where actual delivery of a product will eventually take place, and in afinancial sense, where only money will change hands based on futuremarket value. They often trade these commodities with eachother—exchanging different quantities of the same commodity severaltimes during a given month, week or day. Because of this web of tradingcontracts, the financial exposure between two companies might bemillions of dollars on any given day.

Trading companies use two simple techniques to reduce their creditrisks: collateral and netting (also called set-off). Based on thefinancial strength of their trading partners, companies have requiredthe posting of collateral prior to any trading. Generally, a securityinterest is granted in the collateral so that it can be applied to anyunpaid obligations. Trading companies also have included the concept ofnetting in their trading agreements. Netting allows the parties toset-off any amounts they owe each other and only pay the “net” owed fromone party to the other.

Master Netting, Setoff, Security and Collateral Agreements create aglobal view of the energy trading business, recognizing that most of theplayers are trading multiple commodities between multiple affiliates andsubsidiaries. The master netting agreement links all underlyingcommodity-trading agreements between two companies into a single,integrated agreement. This integration is important because it preventsa bankrupt trading party from choosing and excluding commoditytransactions based on whether or not the transactions are favorable tothe bankrupt party. In addition, the agreement allows the parties toadopt a uniform definition of events that will constitute default underall trading agreements between the parties. The agreement also allowsthe parties to adopt a uniform method by which transactions under alltrading agreements will be terminated and liquidated in the event of adefault. These provisions bring consistency to this liquidation process,which might otherwise be chaotic as the non-defaulting party tries toapply different calculation provisions for different commodities. Thisconsistency also is important because it prevents uncertainties in theliquidation process from delaying the final closeout of obligationsbetween the parties. Further, the agreement encourages the parties tonet monthly payments that they owe each other under all of theunderlying trading agreements. Such “cross-product” and“cross-affiliate” netting reduces the cash demands on both parties andgreatly reduces their overall credit exposure. Finally, the agreementestablishes a single collateral-posting requirement between the partiesto cover the total exposure under all of the underlying tradingagreements. This provision reduces the total amount of collateral thateach party is required to provide and in turn makes more of their“credit” available for trading activities with other companies.

Collateral and guarantees 214 represents contractual arrangements thatprovide collateral and guarantees against transactions 202 and contractsand netting agreements 212, whether provided by a counterparty or thirdparty guarantor. Credit limits and ratings 216 represents credit ratinginformation collected from various third party sources on each of thecounterparties and includes credit limits set by the organization thattriggers certain events if exceeded by a counterparty.

Also represented in FIG. 2 are the calculation formulas 218, whichinclude an external exposure formula 220 and a reverse exposure formula222. Exposure formula 220 represents a mathematical equation selected tomodel the financial exposure of the organization as a function of thedeals 202 and counterparty information 208. Exposure is the amount ofcredit risk exposure all internal counterparties have to a specificexternal counterparty. Reverse exposure formula 222 represents anequation selected to model the reverse exposure the organizationsubjects on its counterparties. Reverse Exposure is the amount of creditrisk exposure all external counterparties have to a specific internalcounterparty.

Credit exposure module 105 contains a calculation engine 224 thatreceives as inputs the transactions 202, counterparty information 208and calculation formulas 218. In particular, calculation engine 224computes exposure formula 220 and reverse exposure formula 222 using, asinputs, the billed cash exposure components 204, unbilled cash exposurecomponents 206, forward exposure components 208, counterparty hierarchy210, contracts and netting agreements 212, collateral and guarantees 214and credit limits and ratings 216. The outputs of calculation engine 224are the calculation results 226. Calculation results 226 present anexposure and reverse exposure calculation 228, an available creditcalculation 230, a collateral and posted calculation 232, a collateraldue calculation 234 and a utilized guarantees determination 236.

With reference now to FIG. 3, there is shown a hierarchical chart 300representing the organizational structure and legal relationships of aparent counterparty and its affiliated legal entities, as utilized in apreferred embodiment of the present invention. As seen in this exampleof a counterparty structure 300, there is shown a parent counterpartycorporation 302 at a parent counterparties level 330. Two legal entitycounterparties represented by the North American subsidiary 304 andEuropean subsidiary 306 are at the legal entity counterparties level332. As will be appreciated, while only a single level of counterparties332 are shown in the example of FIG. 3, any number of levels ofcounterparties could be formed by the hierarchical structure, eitherbelow or above the counterparties level.

Parent counterparty corporation 302 and/or North America subsidiary 304and European subsidiary 306 has entered into four master agreements308-314 at master agreements level 334 with the organization or one ofits legal entities. The power west master agreement 308 and power eastmaster agreement 310 have been entered into with the North Americansubsidiary 304, while the gas master agreement 312 and power masteragreement 314 have been entered into with the European subsidiary 306 ofthe parent corporation 302. As will be appreciated, while only a singlelevel of master agreements 334 are shown in the example of FIG. 3, anynumber of levels of master agreements could be formed by thehierarchical structure, either below or above the master agreement level334.

Last, the hierarchical tree structure 300 has a transaction level 336that indicates the specific transactions 316-328, which have beenentered into with each of the legal entity counterparties 304, 306 underthe master agreements 308-314. Thus, the organizational structure 300presents the diagram of the legal relationships between the transactionsin which the organization has entered into with the parent counterpartycorporation and/or each of its legal entity subsidiaries. As will beappreciated, transactions 316-328 can also be directly connected toparent counterparty 302 without being covered in a master agreement.Also shown in FIG. 3 is a non-trading guarantor 330 legally committed toguarantee one or more of the transactions 316-328 or master agreements308-314 up to a predefined guaranteed limit.

With reference now to FIG. 4, there is shown an example scenario of acredit exposure calculation, in accordance with the preferred embodimentof the present invention. Within each circle representing an entity oragreement, a dollar amount of financial obligations the transactionrepresents is shown in millions. A positive number indicates theexposure to the organization represented by the cumulative financialexposure deriving from all of the obligations and netting/offsettingrights linked from lower levels in the hierarchy and at that node in thehierarchical tree 300. A negative number represents the reverse exposureor value of the transactions held by the organization and negativelyimpacts the counterparty in the event of default.

In this example, the organization and parent counterparty or legalentity counterparties have entered into a master netting and closeoutsetoff agreements 404, 402 to allow the parties to net collateralobligations and set off rights across transactions to achieve a singleamount owed between the parties to the master agreements. When masternetting agreements are utilized across affiliates, they permitaffiliates to net their obligations to post collateral and therebydecrease the net amount each family of companies post to the other.Master netting agreements can provide similarly valuable rights in thecontext of closeout setoff. When a family of companies suffers an eventof default, companies can net closeout amounts owed to the defaultingparties and their affiliates against closeout amounts owed by thenon-defaulting parties and their affiliates. Moreover, master nettingagreements enable entities to provide that all contracts share the sameevents of default, early termination and liquidation rights, and set offprovisions.

In the example shown in FIG. 4, a closeout setoff 402 has been appliedto the master agreements 308, 310 entered into by North Americansubsidiary 304. Also seen in FIG. 4 is settlement amount nettingarrangement 404 between the counterparties and the organization.

Credit exposure 105 calculates the impact to the organization of adefault on one or more of the transactions 316-328. For this example, itis assumed that the legal entity counterparties 304 and 306 default on atotal of $12M in obligations in transactions 324 and 328. As can beenseen, the net exposure to North American subsidiary 304 was a reverseexposure of −$1M due to the closeout setoff 402 of the master agreements308 and 310 (at a minus $10M and plus $9M, respectively). The settlementamount netting arrangement 404 results in a net exposure of +$1M fromthe gas master agreement 312. Also shown is a $3M guarantee agreementbetween the European subsidiary 306 and the non-trading guarantor 330.Thus, where the European subsidiary 306 defaults on $12M of obligationstransactions 324 and 328, the credit exposure application 105 showsexposure of +$4M as a net exposure to the counterparty 306. This resultsbecause of the settlement amount netting 404 producing a net exposure of$1M from the gas master agreement 312 and the full exposure of $6M frompower master agreement 314 because of a lack of a settlement amountnetting agreement for that master agreement. The cumulative $7M inexposure from master agreements 312, 314 is offset by the offsettingprotection of $3M from the non-trading guarantor 330, leaving anexposure calculation of $4M at the European subsidiary 306. Because thecloseout setoff agreement insulates the reverse exposure from the NorthAmerican subsidiary, the entire exposure at parent counterpartycorporation 302 is $4M.

With reference now to FIG. 5, there is shown a flow diagram of a processimplemented by credit exposure module 105, in accordance with apreferred embodiment of the present invention. Process 500 begins atstep 502, where calculation engine 224 calculates the financial exposurethe organization has to the specified transactions 202. Exposure andreverse exposure calculations 228 are computed by applying the exposureformula 220 and reverse exposure formulas 222 to the exposure components204, 206 and 208 and deal attributes 208 in order to calculate a deallevel (transactions 316-328) result of financial exposure to the deal.

At step 504, the exposure on Master Purchase and Sale Agreements (MPSAs)is calculated across all legal entity counterparties within thehierarchy of the parent counterparty hierarchy. The calculation at step504 applies the netting and setoff rules within the MPSA level withrespect to all deals that apply to a particular MPSA. This “rolls up”the exposure calculation from all deals to the MPSA level. This can beseen in FIG. 6 for the payment netting method at MPSA level 604. Thecalculation at step 504 further includes applying the collateral termsof the MPSA to the exposure calculation to determine the collateral duefrom the counterparty.

At step 506, the exposure numbers are modified based on the masternetting and setoff agreements (MNSAs) with the counterparty. At thisstep, the netting and setoff rules resulting from the MNSA are appliedwhen summing up exposures from the plurality of MPSA's with thecounterparty. In addition, collateral terms are applied to the exposurecalculation to determine collateral due of the MNSA governs collateral.As seen in FIG. 6, this step is performed at MNSA level 606, at thecalculation shown at step 622, 624 and 626. The impact of guarantees onthe exposure levels calculated based on MPSA and MNSA level results iscalculated at step 508. At step 510, a counterparty “rollup” is createdacross the entire hierarchy of the counterparty by summing allcalculated exposures at all levels of the counterparty hierarchy. Thisis seen in FIG. 6 at counterparty level 608, where steps 628, 630 and632 are performed.

With reference now to FIG. 6, a data flow diagram of calculation stageswithin the calculation engine is shown, in accordance with a preferredembodiment of the present invention. The particular embodiment shown inFIG. 6 is a flow diagram of the exposure calculation using a paymentnetting method, in accordance with the preferred embodiment of thepresent invention. Data flow diagram 600 is split into multiple stagesof calculation for calculation engine 224. Process 600 is staged (asindicated by dashed lines) into deal level 602, Master Purchase and SaleAgreement (MPSA) level 604, Master Netting and Setoff Agreements (MNSA)level 606 and counterparty level 608.

At deal level 602, the exposure for all transactions for givencounterparty are calculated at step 610 for the deal level 602 inaccordance with the exposure formula 220. As seen at MPSA level 604, theresulting data is fed to calculation blocks 612, 614 and 616.Calculation block 612 contains a calculation for determining a “low”estimate of the credit exposure based on the calculation 610 by summingall cash components of the deals (C_(deal)) and all forward exposure(MtM) components from each of the deals (M_(deal)). The calculations incalculation block 614 take into account only the positive cashcomponents of the deals (C_(deal)) and positive forward exposure (MtM)components from each of the deals (M_(deal)), thereby giving a “high”estimate of the credit exposure to the counterparty.

At decision block 616, a determination is made whether payment nettingis allowed for the given MPSA. Of not, calculation block 618 performsthe same calculation as the “high” estimate of calculation block 614,but if so, the process proceeds to step 620, which summarizes all cashcomponents of the deals (C_(deal)) and only the positive forwardexposure (MtM) components from each of the deals (M_(deal)).

At the MNSA level 606, all positive cash components of the deals(C_(deal)) and positive forward exposure (MtM) components are summed forall MPSAs in the applicable MNSA at step 622. At step 624, all positivecash components of the deals (C_(deal)) and positive forward exposure(MtM) components are summed for all MPSAs in the applicable MNSAresulting from the high estimate exposure calculation 614. Similarly, atstep 626, all MPSA cash and MtM exposure calculations resulting from thelow estimate exposure calculation 612 for all MPSAs under the applicableMNSA are summed.

At the counterparty level 608, a calculation at step 628 is performed togenerate a rollup of the entire counterparty credit exposure across theentire hierarchy of counterparty entities. The calculation at step 628comprises a sum of all the positive cash and MtM exposure calculationsat the MNSA level 606 and MPSA 604 in combination with the utilizedguarantees of the counterparty. The calculation at step 630 determines a“high” estimate of the rollup credit exposure for the counterpartyacross all hierarchies. Similarly, at step 632, a “low” estimate of thecredit exposure for the counterparty, rolled up across the entirehierarchy of legal entities of the counterparties, is calculated.

With reference now to FIG. 7, there is shown a flow diagram of acontractual view using the closeout setoff method of the credit exposurecalculations, in accordance with a preferred embodiment of the presentinvention. Flow diagram 700 is a contractual view of the credit exposurecalculations performed at deal level 602, MPSA level 604, MNSA level 606and counterparty level 608. Process 700 begins at step 610, where thedeal level credit exposure is calculated for all transactions with thecounterparty. Thereafter, data flows from step 610 to steps 702, 704 and706 to perform a “low” estimate of the credit exposure with thecounterparty and its hierarchy of legal entities through the MPSA level604, MNSA level 606 and counterparty level 608. Similarly, the data flowfrom step 610 through steps 710, 712 and 714 perform a “high” estimateof the credit exposure with the counterparty. Last, the data flow fromstep 610 runs to decision block 716, where it is determined if asettlement setoff is allowed under the MPSA (or potentially a MNSA). Ifso, the process proceeds to step 718, where a settlement setoffcalculation is performed at the MPSA level 604 for each of the cash andMtM exposure calculations for each deal.

If settlement setoff is not permitted, the process proceeds to step 720,where it is determined if payment netting is allowed in the applicableMPSA. If not, a calculation of positive credit exposures are summed atstep 724, and if so, all cash components are netted but only positiveMtM components are summed at step 722. Thereafter, the process proceedsto at the MNSA level 606, where all components at the MNSA level aresummed at step 726. Thereafter, a final credit exposure calculation isperformed at step 728 to perform a counterparty rollup across the entirehierarchy of the counterparty.

With reference now to FIG. 8, there is shown a flow diagram of a view ofthe credit exposure calculations using a margining method, in accordancewith a preferred embodiment of the present invention. Flow diagram 800begins at deal level 602 where all deal level exposure is calculated atstep 610. At MPSA level 604, credit exposure at the MPSA level iscalculated in the same manner as shown in FIG. 7. At MNSA level 606, thehigh and low estimates of credit exposure are calculated in the samemanner as shown in FIG. 7, but the credit exposure calculation flowproceeds to step 802, where all credit exposure components resultingfrom steps 718-724 are summed for all MPSAs in each MNSA with allcollateral setoffs included in the summation. At counterparty level 608,the complete credit exposure calculation for the counterparty across theentire legal entity hierarchy is calculated as shown at step 804. Atsteps 806 and 808, the “high” and “low” estimates of credit exposure forthis counterparty are calculated, respectively.

With reference now to FIG. 9, there is shown a data table forconfiguring the exposure components and formulas to be used incalculating credit exposure for counterparties, in accordance with apreferred embodiment of the present invention. Table 900 shows a row 902for “company A” and a row 904 for “company B”. Each row 902, 904 havecolumns for exposure components 906, exposure formula 908 and reverseexposure formula 910. As shown by the examples in FIG. 9, the exposurecomponents 906 describe the cash and forward components for thecounterparties listed. Exposure formula column 908 lists the particularexposure formula used to calculate each of the cash exposure and forwardexposure calculations implemented in each of the credit exposurecalculation processes 600, 700 and 800. Reverse exposure formula 910describes the methodology for calculating the reverse credit exposurewith each identified counterparty.

FIG. 10 shows a high-level block diagram of a data processing system 10,which may be a high-level computer system, consistent with an embodimentof the invention with which the method, system and program of thepresent invention may advantageously be utilized. The present inventionmay be executed in a variety of systems, including a variety ofcomputing systems and electronic devices under a number of differentoperating systems. In one embodiment of the present invention, thesystem is a portable computing system such as a notebook computer, adesktop computer, a network computer, a midrange computer, a serversystem or a mainframe computer. Therefore, in general, the presentinvention is preferably executed in a computer system that performscomputing tasks such as manipulating data in storage that is accessibleto the computer system. In addition, the computer system preferablyincludes at least one output device and at least one input device.

A computer system, for example computer system 10, can be considered asthree major components: (1) the application programs, such as aspreadsheet or word processing or graphics presentation application,which are used by the user; (2) the operating system that transparentlymanages the application's interactions with other applications and thecomputer hardware; and (3) the computer hardware comprising theprocessor, the random access memories, the actual electronic componentswhich manage the digital bits. The operating system has a kernel which,inter alia, controls the execution of applications, processes, and/orobjects by allowing their creation, termination or suspension, andcommunication; schedules processes/objects of the same or differentapplications on the hardware, allocates memory for those objects,administers free space, controls access and retrieves programs and datafor the user.

As seen in FIG. 10, data processing system or computer system 10comprises a bus 22 or other communication device for communicatinginformation within computer system 10, and at least one processingdevice such as processor 12, coupled to bus 22 for processinginformation. While a single CPU is shown in FIG. 10, it should beunderstood that computer systems having multiple CPUs could be used.Processor 12 may be a general-purpose processor that, during normaloperation, processes data under the control of operating system andapplication software stored in a dynamic storage device such as randomaccess memory (RAM) 14 and a static storage device such as Read OnlyMemory (ROM) 16 and mass storage device 18, all for storing data andprograms. The system memory components are shown conceptually as singlemonolithic entities, but it is well known that system memory is oftenarranged in a hierarchy of caches and other memory devices. Theoperating system preferably provides a graphical user interface (GUI) tothe user. In a preferred embodiment, application software containsmachine executable instructions that when executed on processor 12 carryout the operations and processes of the preferred embodiment describedherein. Alternatively, the steps of the present invention might beperformed by specific hardware components that contain hardwire logicfor performing the steps, or by any combination of programmed computercomponents and custom hardware components.

Communication bus 22 supports transfer of data, commands and otherinformation between different devices within computer system 10; whileshown in simplified form as a single bus, it may be structured asmultiple buses, and may be arranged in a hierarchical form. Further,multiple peripheral components may be attached to computer system 10 viacommunication bus 22. A display 24 such as a cathode-ray tube display, aflat panel display, or a touch panel is also attached to bus 22 forproviding visual, tactile or other graphical representation formats. Akeyboard 26 and cursor control device 30, such as a mouse, trackball, orcursor direction keys, are coupled to bus 22 as interfaces for userinputs to computer system 10. In alternate embodiments of the presentinvention, additional input and output peripheral components may beadded. Communication bus 22 may connect a wide variety of other devices(not shown) to computer system 10 and to other adapters connected toother devices such as, but not limited to, audio and visual equipment,tape drives, optical drives, printers, disk controllers, other busadapters, PCI adapters, workstations using one or more protocolsincluding, but not limited to, Token Ring, Gigabyte Ethernet, Ethernet,Fibre Channel, SSA, Fiber Channel Arbitrated Loop (FCAL), Ultra3 SCSI,Infiniband, FDDI, ATM, ESCON, wireless relays, USB, Twinax, LANconnections, WAN connections, high performance graphics, etc., as isknown in the art.

Communication interface 32 provides a physical interface to a network,such as the Internet 38, or to another network server via a local areanetwork using an Ethernet, Token Ring, or other protocol, the secondnetwork server in turn being connected to the Internet or Local AreaNetwork. Internet 38 may refer to the worldwide collection of networksand gateways that use a particular protocol, such as TransmissionControl Protocol (TCP) and Internet Protocol (IP), to communicate withone another. The representation of FIG. 2 is intended as an exemplarysimplified representation of a high-end computer system, it beingunderstood that in other data processing systems 10, variations insystem configuration are possible in addition to those mentioned here.

The present invention may be provided as a computer program product,included on a machine-readable medium having stored thereon the machineexecutable instructions used to program computer system 10 and/or to aperipheral device for installation on a connected adapter to perform aprocess according to the present invention. The term “machine-readablemedium” as used herein includes any medium, signal-bearing media orcomputer readable storage media that participates in providinginstructions to processor 12 or other components of computer system 10for execution. Such a medium may take many forms including, but notlimited to, non-volatile media, volatile media, and transmission media.Common forms of non-volatile media include, for example, a floppy disk,a flexible disk, a hard disk, magnetic tape or any other magneticmedium, a compact disc ROM (CD-ROM) or any other optical medium, punchcards or any other physical medium with patters of holes, a programmableROM (PROM), an erasable PROM (EPROM), electrically EPROM (EEPROM), aflash memory, any other memory chip or cartridge, or any other mediumfrom which computer system 10 can read and which is suitable for storinginstructions. In the present embodiment, an example of nonvolatile mediais storage device 18. Volatile media includes dynamic memory such as RAM14. Transmission media includes coaxial cables, copper wire or fiberoptics, including the wires that comprise bus 22. Transmission media canalso take the form of electromagnetic, acoustic or light waves, such asthose generated during radio wave or infrared wireless datacommunications. Thus, the programs defining the functions of thepreferred embodiment can be delivered to the data processing system 10information on any machine-readable medium, which include, but are notlimited to: (a) information permanently stored on non-write storagemedia, e.g., read only memory devices within either computer such asCD-ROM disks readable by CD-ROM; (b) alterable information stored onwrite-able storage media, e.g., floppy disks within a diskette drive ora hard-disk drive; or (c) information conveyed to a computer by atelephone or a cable media network, including wireless communications.Such signal-bearing media, when carrying instructions that may be readby an adapter or a computer to direct the functions of the presentinvention, represent alternative embodiments.

A more detailed description of various components of software system 100will now be given. In particular, the operation of the web-based userinterfaces 103 in conjunction with credit exposure module 105 will begiven.

CreditExposure Core

Credit Exposure module 105 generates an enterprise view of anorganization's current and future credit exposure by deal, contract,counterparty and credit limit categories. The credit exposure figureswill contain the sum intelligence of the cash values and the forwardvalues for every deal a trading organization has entered into. The totalexposure will be calculated using all the known payment netting andsettlement amount setoff rules as specified in the Master Purchase andSales Agreements (MPSAs) and the Master Netting and Setoff Agreements(MNSAS) between the organization and its counterparties. Guarantees,collateral and credit limits are also factored into the calculations.

A filter on the “view” specified by web-based user interfaces 103 allowsa user to change the limit allocation used to determine available creditand the calculation method used to calculate exposure and reverseexposure. The filter is used on all pages except deal level exposure andreverse exposure. Additionally, in the limit category page of web-baseduser interfaces 103, the filter does not include the calculation methodparameter. The “limit allocation” drop down should get its values fromthe limit allocations that are defined on the limit template.

There are three options for calculation method: Accounting View,Contractual View, and Margining View. Each of these corresponds to acalculation method used by the exposure calculation engine 224. The“calculation method” drop down gets its values from the codes table.Each page that implements the filter should default to the first limitallocation that is defined and to the “Contractual” calculation method.The user is able to apply the filter on any combination of limitallocation and calculation method.

Selecting the filter options has the following implications, (1)selecting an alternative limit allocation will change the “credit limit”and “available credit” values that are displayed; and (2) selecting analternative calculation method will change the exposure values that aredisplayed and, on the multiple counterparty editor, will change howcontracts rollup to counterparties. In many cases, there is a simplemapping of exposure information that has been calculated by thecalculation engine 224 and the corresponding views of that informationin web-based user interfaces 103. The rules for field sources forexposure information (including information regarding collateral andguarantees) are as follows: Accounting View Contractual View MarginingView Deals Only one calculation method is used for deal levelinformation, since no netting or margining rules apply at that level.MPSAs Payment Netting Method Closeout Setoff Method Closeout SetoffMethod MNSAs Payment Netting Method Closeout Setoff Method MarginingMethod Virtual Netting Payment Netting Method Closeout Setoff MethodCloseout Setoff Method Groups Guarantees for Payment Netting MethodCloseout Setoff Method Closeout Setoff Method MPSAs Guarantees forPayment Netting Method Closeout Setoff Method Margining Method MNSAsCounterparties Payment Netting Method Closeout Setoff Method MarginingMethod Limit Category Only one calculation method is used for creditlimit category level information.Counterparty Summary—Exposure & Reverse ExposurePage Functionality

FIG. 11 shows a screenshot of a web browser page of web-based userinterfaces 103 displaying a summary view of a counterparty's exposure.The user gets to this page by selecting a counterparty. Theexposure/reverse exposure overview chart display the values of the barswhen a user hovers over them. The user should be able to click on thesource name for scores and ratings and get to the detail page for theappropriate score or rating. If no scores or ratings have been createdfor the counterparty, the table should display the “no values” message.The following table shows the fields in the view that are calculated bythe calculation engine 224 and the fields calculated by the view. Sinceonly counterparty-level totals are shown on this view, then thefollowing rules are applied to obtain the appropriate field sources.Note that this rule applies to both exposure numbers and collateralnumbers. All calculation engine fields on this view should vary when thecalculation method is changed (this includes guarantees and collateral).

Limit Category—Exposure & Reverse Exposure

Page Functionality

FIG. 12 shows a screenshot of a web browser page of web-based userinterfaces 103 displaying exposure/reverse exposure by limit category.Only “high” and “low” exposure is displayed in this view. The user getsto this page by selecting the “By Limit Category” sub-navigationelement. If a counterparty is already active, then that counterparty'sinformation is shown. If no counterparty is active when the user gets tothe page, a message should be presented that says “Select a counterpartyfrom the list at left.” The user should be able to click on a limitcategory and be taken to the deals for that category. The link candisplay at all times regardless of if deals are associated to the limitcategory; however, the deals page should display a message that no dealsexist for this limit category.

Multiple Counterparty Rollup—Exposure & Reverse Exposure

Page Functionality

FIG. 13 shows a screenshot of a web browser page of web-based userinterfaces 103 displaying multiple counterparty exposure rollup withinthe counterparty hierarchy. The page displays exposure/reverse exposurefor the active counterparty and one level of child counterparties afterthe active counterparty. The page consolidates counterparty, guarantee,and contract (both MPSA and MNSA) exposure/reverse exposure information.Guarantees are listed beneath the associated (guarantor) counterparty,MNSAs beneath the primary counterparty (internal for reverse exposureand external for exposure), and MPSAs beneath their associated MNSA. Thefollowing table shows the fields in the view that are calculated by thecalculation engine and the fields calculated by the view: Calc ColumnName Engine View Multiple Counterparty Rollup Table Name X *C1-C5(configurable cash components) X The wireframes show examples for“previous month cash”, “current month cash”, and “prompt month cash”*M1-M5 (configurable MtM components) X The wireframes do not show anexample of this. External/Internal Cash Subcomponent (result of Xformula applied to the 5 cash components, C1-C5) The wireframes show anexample for “60-day cash exposure/reverse cash exposure”.*External/Internal MtM Subcomponent (result of X formula applied to the5 MtM components, M1-M5) The wireframes show an example for “forwardexposure/ reverse exposure”. Low Exposure/Reverse Exposure X TotalExposure/Reverse Exposure X High Exposure/Reverse Exposure X CollateralHeld/Posted X Unsecured Exposure/Reverse Exposure X Credit/Trading LimitX Available Credit/Trading Limit X Collateral Threshold X Collateral DueX

The page is subject to the following rules: (1) the active counterpartyis shown on the first row of the grid; (2) immediately below eachcounterparty should appear a row for each guarantee for which thatcounterparty is the guarantor, with the utilized guarantee amount shownas a positive (addition to exposure). These appear indented one level,since this counterparty is the “parent” of the guarantee; and (3) afterall guarantees for which this counterparty is the guarantor is shown,the next set of items shown should be MNSAs for which this counterpartyis the primary counterparty. MNSAs are shown at the same level ofindentation as guarantees.

As a result, this page selects the correct set of numbers from theresults of the calculation engine 224, based on the following rules:Accounting View Contractual View Margining View MPSAs Payment NettingMethod Closeout Setoff Method Closeout Setoff Method MNSAs PaymentNetting Method Closeout Setoff Method Margining Method Virtual NettingGroups Payment Netting Method Closeout Setoff Method Closeout SetoffMethod Guarantees for MPSAs Payment Netting Method Closeout SetoffMethod Closeout Setoff Method Guarantees for MNSAs Payment NettingMethod Closeout Setoff Method Margining Method Counterparties PaymentNetting Method Closeout Setoff Method Margining Method

If an MPSA is part of an MNSA, then it appears below its MNSA (indented,since the MNSA is the parent) as well as appearing below the primarycounterparty. When such an MPSA appears in its normal position below acounterparty, all number values should be replaced with “N/A”. Note thatall affected MPSAs are listed in this case, even if the activecounterparty is not the primary counterparty on all of those MPSAs. Notethat the requirement for being “part of an MNSA” changes based on thecalculation method specified for the view as shown below.

In the views Accounting and Contractual, all MPSAs that have been addedas “affected contracts” for the MNSA are shown under the MNSA. A smallersubset of MPSAs are shown under the MNSA in the Margining view. Of theset of MPSAs listed as “affected contracts” for the MNSA, only those forwhich “setoff for margining” is set to true appears under the MNSA. If avirtual netting group was created because of closeout setoff acrosscontracts (defined at the MPSA level), then the virtual netting groupappears like an MNSA would appear. The same rules should apply, but thename of the virtual netting group should simply be “Setoff Group”. AllMPSAs for which the counterparty is the primary counterparty shouldappear at the same level as MNSAs for this counterparty. As noted above,any MPSA that is part of a MNSA will appear twice (once in its normalposition and once under the MNSA). Guarantees will appear several timesin the rollup. They should appear once after the guarantor, in whichtheir utilized guarantee amount appears as a positive contribution toexposure. They also appear below each set of affected MPSAs for a givencounterparty with the utilized amount shown as a negative. If aguarantee in which this counterparty is the guaranteed counterpartyappears, it is indented from the affected MPSA, since the MPSA is its“parent.” Counterparties are shown under their parent counterparties.The same rules described above apply to each level of counterparty thatis shown on the page. Fields that have null values are shown as “N/A” inthe view pages.

Contracts Summary

Page Functionality

FIG. 14 shows a screenshot of a web browser page of web-based userinterfaces 103 displaying a summary list of the contracts (both MPSAsand MNSAs) that have been created for the counterparty. The user gets tothis page by selecting the “Contracts” sub-navigational element withinthe Exposure tab. A counterparty does not need to be a primarycounterparty for the contract to appear in this view. For the MPSAsection of the page, the user can click on the “contract id” and betaken to the view page for the contract. For the MSNA section of thepage, the user can select the “MNSA id” and be taken to the view pagefor that MNSA. If the user clicks on one of the “Affected MPSAs”, he orshe will be taken to the view page for that MPSA contract. The followingcolumns are shown in the view:

-   -   Contract id or MNSA id    -   Status    -   Commodity    -   Trade Area    -   Internal Counterparties    -   External Counterparties    -   Deal Category    -   Effective Date    -   End Date        Exposure Formula Configuration

Credit exposure module 105 supports the ability to configure an exposureand reverse exposure formula and support the ability for the configuredformula to be included into the code base. An exposure formula consistsof both a cash formula and forward formula. The following are all thepossible formula attributes for the cash portion of the formula: C1-C5,Deal Category, Commodity, Today's Date, Scheduled Payment Date,Transaction Date, Buy, Trade Area, Duration, and Deal Type. Thefollowing are all the possible formula attributes for the forwardportion of the formula: F1-F5, Deal Category, Commodity, Today's Date,Scheduled Payment Date, Transaction Date, Buy, Trade Area, Duration, andDeal Type.

Calculation Engine

The following section outlines the algorithms and business rules used tocalculate credit exposure. The deal is the most atomic data element inthe credit exposure calculations—all exposure values are derived fromthe deal and its cash and forward subcomponents (C1-5 and M1-5,respectively). C1 C2 C3 C4 C5 M1 M2 M3 M4 M5 Deal1 c1_(deal1) c2_(deal1)c3_(deal1) c4_(deal1) c5_(deal1) m1_(deal1) m2_(deal1) m3_(deal1)m4_(deal1) m5_(deal1) Deal2 c1_(deal2) c2_(deal2) c3_(deal2) c4_(deal2)c5_(deal2) m1_(deal2) m2_(deal2) m3_(deal2) m4_(deal2) m5_(deal2) . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dealnc1_(dealn) c2_(dealn) c3_(dealn) c4_(dealn) c5_(dealn) m1_(dealn)m2_(dealn) m3_(dealn) m4_(dealn) m5_(dealn)

Credit exposure module 105 allows for customer configurable formulas forboth total deal cash exposure and total deal forward exposure. Althoughother parameters or terms (T) may be used in each formula to defineconditions, the resulting computed values are derived entirely from thedeal subcomponents C1-5 and M1-5.Total Cash Exposure=TCE(T, C1-5)Total Forward Exposure=TFE(T, M1-5)

The total cash exposure and total forward exposure is then calculatedfor each deal based upon the stated formulas. The total exposure foreach deal is defined as the sum of the total cash exposure and totalforward exposure (TCE+TFE). The cash exposure, forward exposure andtotal exposure are now known for each deal, and subsequent groupings andcalculations may now be performed. Total Total Cash Exposure TotalForward Exposure Exposure (A) (B) (C) Deal1 TCE(T, c1_(deal1) −c5_(deal1)) TFE(T, m1_(deal1) − m5_(deal1)) (A)_(deal1) + (B)_(deal1)Deal2 TCE(T, c1_(deal2) − c5_(deal2)) TFE(T, m1_(deal2) − m5_(deal2))(A)_(deal2) + (B)_(deal2) . . . . . . . . . . . . Dealn TCE(T,c1_(dealn) − c5_(dealn)) TFE(T, m1_(dealn) − m5_(dealn)) (A)_(dealn) +(B)_(dealn)MPSA

Deal-level exposure can be rolled up to the MPSA level. Every deal isassociated with exactly one MPSA. There are four different ways toaggregate exposure at the MPSA level:

-   -   1. Payment Netting (or “Accounting View”)    -   2. Closeout Setoff (or “Contract View”)    -   3. No Netting or Setoff (or “High”)    -   4. All Possible Netting and Setoff (or “Low”)        Payment Netting (“Accounting View”) Exposure

To aggregate deal exposure values (C1-5, M1-5, total cash exposure andtotal forward exposure) at the MPSA level using the payment nettingcalculation method use the following rules: Allow invoice/ Forwardpayment netting? Cash Exposure Exposure Total Exposure No Σ positivenumbers Σ positive Σ positive numbers numbers Yes Σ all numbers Σpositive Σ positive numbers numbers

Total exposure is calculated as the sum of the positive deal totalexposures with no regard to the payment netting status. This must bedone because negative cash exposures should not reduce positive forwardexposures.MPSA Total Exposure=Σ Positive Deal Total Exposure

To determine whether an MPSA allows invoice/payment netting, use thevalue specified by: MPSA Associated MNSA Use payment netting with MNSA?payment netting allowed? allowed from . . . No N/A MPSA Yes No MNSA YesYes MNSA Yes Null MPSACloseout Setoff (“Contract View”) Exposure

To aggregate deal exposure values (C1-5, M1-5, total cash exposure andtotal forward exposure) at the MPSA level using the closeout setoffcalculation method use the following rules: Allow invoice/ Allow setoffof payment netting? settlement amounts? Cash Exposure Forward ExposureTotal Exposure No No Σ positive numbers Σ positive numbers Σ positivenumbers Yes No Σ all numbers Σ positive numbers Σ positive numbers X YesΣ all numbers Σ all numbers Σ all numbers

To determine whether an MPSA allows invoice/payment netting, see tablein previous section. To determine whether an MPSA allows setoff ofsettlement amounts, use the value specified by: MNSA or Virtual NettingMPSA Associated Group closeout Use closeout setoff with MNSA? setoffallowed? allowed from . . . No N/A MPSA Yes No MNSA Yes Yes MNSA YesNull MPSANo Netting or Setoff Setoff (“High”) Exposure

To aggregate deal exposure values at the MPSA level using no netting orsetoff, sum only positive numbers for total cash and total forwardexposure. Note that “high” exposure is currently only calculated fortotal exposure. The “high” exposure for a given MPSA is defined as thesum of all its deals' positive total exposures. “High” exposure iscurrently not calculated for any of the cash or forward subcomponents.MPSA Total High Exposure=Σ Positive Deal Total ExposuresAll Possible Netting and Setoff (“Low”) Exposure

To aggregate deal exposure values at the MPSA level using all possiblenetting and setoff, sum all numbers for total cash and total forwardexposure. The “low” exposure for a given MPSA is defined as the sum ofall its deals' total exposures. “Low” exposure is currently notcalculated for any of the cash or forward subcomponents.MPSA Total Low Exposure=Σ All Deal Total ExposuresCollateral Held

Collateral can be applied to either one MNSA or one or more MPSAs. AnMPSA may have zero or more collateral amounts applied to it. Todetermine the total collateral held for a given MPSA, sum allvaluation-adjusted collateral amounts that are applied to that MPSA andare “taken”.MPSA Collateral Held=Σ (Collateral Amount*Valuation %) for all “taken”Collateral applied to that MPSA and currently in effect. Being in effectmeans that today's date is >=the effective date of the collateraland<=the end date of the collateral.

Utilized collateral held is also determined at the MPSA level and isdefined as MPSA collateral held up to but not exceeding the totalexposure. If the amount of MPSA collateral held is greater than thetotal exposure, the utilized collateral held is equal to the totalexposure. Note that utilized collateral held is calculated for paymentnetting and closeout setoff using the respective total exposures.Utilized collateral is set to 0 if MNSA level collateral is in effect.

MNSA

MPSA-level exposure can be rolled up to the MNSA level. Every MPSA isassociated with zero or one MNSAs. An MPSA may only participate in onenetting agreement (either MNSA or a virtual netting group). There arefive different ways to aggregate exposure at the MNSA level:

-   -   1. Payment Netting (or “Accounting View”)    -   2. Closeout Setoff (or “Contract View”)    -   3. Margining    -   4. No Netting or Setoff (or “High”)    -   5. All Possible Netting and Setoff (or “Low”)        Payment Netting Exposure

To aggregate MPSA exposure values (C1-5, M1-5, total cash exposure,total forward exposure and total exposure) at the MNSA level using thepayment netting calculation method, sum positive MPSA payment nettingnumbers for MPSAs associated with the MNSA if the allow payment nettingflag (on the MNSA) is true for the given MPSA. If the flag is false onlyadd the exposure for that MPSA if the exposure is positive. Allowinvoice/ Total payment netting? Cash Exposure Forward Exposure ExposureNo Σ positive numbers Σ positive numbers Σ positive numbers Yes Σ allnumbers Σ positive numbers Σ positive numbers

Total MNSA exposure is calculated as the sum of the positive total MNSAexposures.

Closeout Setoff Exposure

To aggregate MPSA exposure values (C1-5, M1-5, total cash exposure,total forward exposure and total exposure) at the MNSA level using thecloseout setoff calculation method sum all MPSA closeout setoff numbersfor all MPSAs associated with the MNSA.MNSA Closeout Setoff Numbers=Σ All MPSA Closeout Setoff NumbersSetoff is implied between all MPSAs associated with an MNSA.Margining Exposure

To aggregate MPSA exposure values (C1-5, M1-5, total cash exposure,total forward exposure and total exposure) at the MNSA level using themargining calculation method sum all MPSA closeout setoff numbers forall MPSAs that meet the following conditions:

-   -   The MNSA “Margining Required” is yes.    -   The MNSA “Margining Governed by this Contract” for the specific        MPSA is yes.    -   The MNSA “Setoff for Collateral Requirements” for the specific        MPSA is yes.        MNSA Margining Numbers=Σ Closeout Setoff Numbers for MPSAs that        meet the stated conditions

If the MNSA “Margining Required” is no or no MPSAs exist for the MNSAwhere “Margining Governed by this Contract” is yes and “Setoff forCollateral Requirements” is yes, then the MNSA has no marginingexposure.

No Netting or Setoff (“High”) Exposure

To aggregate MPSA total high exposure at the MNSA level using no nettingor setoff, sum all MPSA total high exposure numbers.MNSA Total High Exposure=Σ All MPSA Total High Exposures

Note that normally only positive numbers would be summed to enforce nonetting or setoff. However, only positive numbers were summed at theMPSA level so it is not necessary to test for positive numbers at theMNSA level.

All Possible Netting and Setoff (“Low”) Exposure

To aggregate MPSA total high exposure at the MNSA level using allpossible netting and setoff, sum all MPSA total low exposure numbers.MNSA Total Low Exposure=Σ All MPSA Total Low ExposuresPayment Netting

For payment netting, sum the “taken” collateral held at the MNSA levelwith the utilized “taken” collateral held applied to MPSAs associatedwith the MNSA if the MPSA has positive total exposure calculated withthe payment netting method:Payment Netting MNSA Collateral Held=Σ (Collateral Amount*Valuation %)for all “taken” Collateral applied to that MNSA+Σ (CollateralAmount*Valuation %) for “taken” Utilized Collateral applied to MPSAswith Positive Payment Netting Total ExposureCloseout Setoff

For closeout setoff, sum the “taken” collateral held at the MNSA levelwith the utilized “taken” collateral held applied to all MPSAsassociated with the MNSA:Closeout Setoff MNSA Collateral Held=Σ (Collateral Amount*Valuation %)for all “taken” Collateral applied to that MNSA+Σ (CollateralAmount*Valuation %) for “taken” Utilized Collateral applied to all MPSAsMargining

For margining, sum the “taken” collateral held at the MNSA level withthe utilized “taken” collateral held applied to MPSAs associated withthe MNSA if the following conditions are met:

-   -   1. The MNSA “Margining Required” is yes.    -   2. The MNSA “Margining Governed by this Contract” for the        specific MPSA is yes.    -   3. The MNSA “Setoff for Collateral Requirements” for the        specific MPSA is yes.        Margining MNSA Collateral Held=Σ (Collateral Amount*Valuation %)        for all “taken” Collateral applied to that MNSA+Σ (Collateral        Amount*Valuation %) for “taken” Utilized Collateral applied to        MPSAs that meet the stated conditions        Guarantee Associated with MNSA

A guarantee can be associated with only one MNSA. The availableguarantee amount is applied to the MNSA's total exposure until the totalamount of the guarantee has been applied. For a guarantee that isassociated with an MNSA, there are five ways to calculate utilizedamount:

-   -   1. Payment Netting (or “Accounting View”)    -   2. Closeout Setoff (or “Contract View”)    -   3. Margining    -   4. No Netting or Setoff (or “High”)    -   5. All Possible Netting and Setoff (or “Low”)        Counterparty

Exposure can be rolled up to the counterparty level for externalcounterparties. Counterparty-level exposure is comprised of exposurefrom the following elements in which the counterparty is specified asthe external (and primary, where applicable) counterparty:

-   -   1. MNSAs    -   2. Virtual Netting Groups    -   3. MPSAs that are not in MNSAs or Virtual Netting Groups    -   4. Guarantees (both given and received). Guarantees are only        applied to total exposure and unsecured exposure. They are not        applied to collateral numbers or cash and forward component        numbers.

There are five different ways to aggregate exposure at the counterpartylevel:

-   -   1. Payment Netting (or “Accounting View”)    -   2. Closeout Setoff (or “Contract View”)    -   3. Margining    -   4. No Netting or Setoff (or “High”)    -   5. All Possible Netting and Setoff (or “Low”)        Payment Netting

To aggregate exposure values (C1-5, M1-5, total cash exposure, totalforward exposure and total exposure) at the counterparty level using thepayment netting calculation method sum positive MPSA payment nettingnumbers for all MPSAs where the counterparty is the primary and the MPSAis not in an MNSA, all MNSA payment netting numbers where thecounterparty is the primary, and all guarantees associated with thecounterparty.

Counterparty Payment Netting Numbers=Σ All MNSA Payment Netting Numbers+All Virtual Netting Group Payment Netting Numbers+All Positive MPSAPayment Netting Numbers (not in MNSA or VNG)+All Payment NettingUtilized Guarantees in which this CP is the Guarantor−All PaymentNetting Utilized Guarantees in which this CP is the primary CP for theMPSA or MNSA

There is no payment netting between MPSAs and the payment netting withineach MPSA was already taken into account when the MPSA payment nettingnumbers were calculated.

Closeout Setoff

To aggregate exposure values (C1-5, M1-5, total cash exposure, totalforward exposure and total exposure) at the counterparty level using thecloseout setoff calculation method sum all closeout setoff numbers forall MNSAs, Virtual Netting Groups, MPSAs (not in MNSAs or VirtualNetting Groups) and Guarantees associated with the counterparty.

Counterparty Closeout Setoff Numbers=Σ All MNSA Closeout SetoffNumbers+All Virtual Netting Group Closeout Setoff Numbers+All MPSA (notin MNSAs or Virtual Netting Groups) Closeout Setoff Numbers+All CloseoutSetoff Utilized Guarantees in which this CP is the Guarantor−AllCloseout Setoff Utilized Guarantees in which this CP is the primary CPfor the MPSA or MNSA

Margining

To aggregate exposure values (C1-5, M1-5, total cash exposure, totalforward exposure and total exposure) at the counterparty level using themargining calculation method sum all margining numbers for all MNSAs,Virtual Netting Groups, MPSAs (not in MNSAs or Virtual Netting Groups)and Guarantees associated with the counterparty.

Counterparty Margining Numbers=Σ All MNSA Margining Numbers+All VirtualNetting Group Margining Numbers+All MPSA (not in MNSA or VNG or whoseMNSA “setoff for collateral requirements” is “No”)Closeout SetoffNumbers+All Margining Utilized Guarantees in which this CP is theGuarantor−All Margining Utilized Guarantees in which this CP is theprimary CP for the MPSA or MNSA

To aggregate total high exposure at the counterparty level using nonetting or setoff, sum all total high exposure numbers.Counterparty Total High Exposure=Σ All MNSA Total High Exposures+AllVirtual Netting Group Total High Exposures+All MPSA (not in MNSAs orVirtual Netting Groups) Total High Exposures+All High UtilizedGuarantees in which this CP is the Guarantor−All High UtilizedGuarantees in which this CP is the primary CP for the MPSA or MNSA

Note that normally only positive numbers would be summed to enforce nonetting or setoff. However, positive numbers were summed at the MPSAlevel so it is not necessary to test for positive numbers at the MNSAlevel.

All Possible Netting and Setoff (“Low”)

To aggregate total low exposure at the counterparty level using allpossible netting and setoff, sum all total low exposure numbers.Counterparty Total Low Exposure=Σ All MNSA Total Low Exposures+AllVirtual Netting Group Total Low Exposures+All MPSA (not in MNSAs orVirtual Netting Groups) Total Low Exposures+All Low Utilized Guaranteesin which this CP is the Guarantor−All Low Utilized Guarantees in whichthis CP is the primary CP for the MPSA or MNSACollateral Held

Collateral held is determined at the counterparty level using thepayment netting, closeout setoff and margining methods. For all threemethods, the total collateral held for the counterparty is determined bysumming the respective collateral held for all MNSAs and utilizedcollateral held for MPSAs not in MNSAs.Counterparty Collateral Held=Σ All MNSA Collateral Held+All MPSA (not inMNSA) Utilized Collateral HeldCounterparty Roll Up

Counterparty exposure is also rolled up between counterparties using theHalo, or “moral responsibility”, method. Using the Halo method, everyparent counterparty accepts not only exposure from the MPSA, MNSA, VNGand guarantees that it directly participates in but also accepts the sumexposure of all of its children.Halo Counterparty Exposure Numbers=Counterparty Exposure Numbers+Σ AllChildren Exposure Numbers

Once the Halo numbers are calculated, each counterparty is ranked indescending order according to total exposure. Additionally, the share ofcorporate exposure is calculated.Share of Corporate Exposure=(Total Counterparty Exposure/Σ AllCounterparties' Exposure)*100%

While the invention has been particularly shown and described withreference to a preferred embodiment, it will be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the invention.For example, the present invention may be implemented using anycombination of computer programming software, firmware or hardware. As apreparatory step to practicing the invention or constructing anapparatus according to the invention, the computer programming code(whether software or firmware) according to the invention will typicallybe stored in one or more machine readable storage mediums such as fixed(hard) drives, diskettes, optical disks, magnetic tape, semiconductormemories such as ROMs, PROMs, etc., thereby making an article ofmanufacture in accordance with the invention. The article of manufacturecontaining the computer programming code is used by either executing thecode directly from the storage device, by copying the code from thestorage device into another storage device such as a hard disk, RAM,etc. or by transmitting the code for remote execution. The method formof the invention may be practiced by combining one or moremachine-readable storage devices containing the code according to thepresent invention with appropriate standard computer hardware to executethe code contained therein. An apparatus for practicing the inventioncould be one or more computers and storage systems containing or havingnetwork access to computer program(s) coded in accordance with theinvention.

1. A method comprising: creating a hierarchical model of legallyassociated counterparties and associated transactions with anorganization, wherein the hierarchical model includes one or morecounterparty levels containing the legally associated counterparties,and one or more master levels containing one or more master agreements,each master agreement being between one of the legally associatedcounterparties and the organization, and one or more transaction levelscontaining one or more transactions, wherein each master agreementprovides one or more mechanisms for financial aggregation of associatedtransactions between one or more of the counterparties and theorganization; and calculating aggregate financial exposure for theorganization at each level of the hierarchical model based on the one ormore master agreements and their associated transactions.
 2. A methodaccording to claim 1, wherein creating a hierarchical model furthercomprises creating a hierarchical model having: a root node representinga parent counterparty; one or more counterparty levels in thehierarchical model structured by parent-child relationships between oneor more counterparties legally associated with the parent counterparty,each counterparty of the one or more counterparties being represented ata node of the counterparty levels, wherein one or more of thecounterparty levels is linked to the root node; one or more masterlevels in the hierarchical model representing parent-child relationshipsbetween one or more agreements, wherein each node in the one or moremaster levels represents an agreement with one or more of the one ormore counterparties that provides one or more mechanisms for financialaggregation of transactions at a lower level in the hierarchical model,and wherein one of the master levels is linked to one of thecounterparty levels; and a plurality of leaf nodes, each representing atransaction with the one or more of the one or more counterparties, eachleaf node of the plurality of leaf nodes being linked to one or morenodes of the one or more master levels or one or more nodes of the oneor more counterparty levels.
 3. A method according to claim 1, whereincalculating aggregate financial exposure includes: calculatingtransactional financial exposure at each leaf node resulting from eachof the one or more transactions; calculating master-level financialexposure at each node of the one or more master levels of thehierarchical model, wherein master-level financial exposure at a givenmaster-level node is calculated as a function of the financial exposureof nodes at a lower level of the hierarchical model linked to the givenmaster-level node; calculating counterparty-level financial exposure ateach node of the one or more counterparty levels of the hierarchicalmodel, wherein counterparty-level financial exposure at a givencounterparty-level node is calculated as a function of the financialexposure of nodes at a lower level of the hierarchical model linked tothe given counterparty-level node; and generating an aggregate financialexposure for the organization based on an aggregation of thecounterparty-level financial exposure.
 4. A method according to claim 1,wherein aggregate financial exposure is calculated using a paymentnetting method.
 5. A method according to claim 1, wherein aggregatefinancial exposure is calculated using a closeout setoff method.
 6. Amethod according to claim 1, wherein aggregate financial exposure iscalculated using a margining method.
 7. A method according to claim 1,wherein aggregate financial exposure is calculated using a method usingall possible netting and setoff.
 8. A method according to claim 1,further comprising calculating financial exposure for each masteragreement in a master agreement level.
 9. A method according to claim 1,further comprising calculating financial exposure for each counterpartyin a counterparty level.
 10. A method according to claim 1, furthercomprising calculating financial exposure based on netting, setoff,margin, and collateral requirements.
 11. An article of manufacturecomprising machine-readable medium including program logic embeddedtherein that causes control circuitry in a data processing system toperform the steps of: creating a hierarchical model of legallyassociated counterparties and associated transactions with anorganization, wherein the hierarchical model includes one or morecounterparty levels containing the legally associated counterparties,and one or more master levels containing one or more master agreements,each master agreement being between one of the legally associatedcounterparties and the organization, and one or more transaction levelscontaining one or more transactions, wherein each master agreementprovides one or more mechanisms for financial aggregation of associatedtransactions between one or more of the counterparties and theorganization; and calculating aggregate financial exposure for theorganization at each level of the hierarchical model based on the one ormore master agreements and their associated transactions.
 12. An articleof manufacture according to claim 11, wherein creating a hierarchicalmodel further comprises creating a hierarchical model having: a rootnode representing a parent counterparty; one or more counterparty levelsin the hierarchical model structured by parent-child relationshipsbetween one or more counterparties legally associated with the parentcounterparty, each counterparty of the one or more counterparties beingrepresented at a node of the counterparty levels, wherein one or more ofthe counterparty levels is linked to the root node; one or more masterlevels in the hierarchical model representing parent-child relationshipsbetween one or more agreements, wherein each node in the one or moremaster levels represents an agreement with one or more of the one ormore counterparties that provides one or more mechanisms for financialaggregation of transactions at a lower level in the hierarchical model,and wherein one of the master levels is linked to one of thecounterparty levels; and a plurality of leaf nodes, each representing atransaction with the one or more of the one or more counterparties, eachleaf node of the plurality of leaf nodes being linked to one or morenodes of the one or more master levels or one or more nodes of the oneor more counterparty levels.
 13. An article of manufacture according toclaim 11, wherein calculating aggregate financial exposure includes:calculating transactional financial exposure at each leaf node resultingfrom each of the one or more transactions; calculating master-levelfinancial exposure at each node of the one or more master levels of thehierarchical model, wherein master-level financial exposure at a givenmaster-level node is calculated as a function of the financial exposureof nodes at a lower level of the hierarchical model linked to the givenmaster-level node; calculating counterparty-level financial exposure ateach node of the one or more counterparty levels of the hierarchicalmodel, wherein counterparty-level financial exposure at a givencounterparty-level node is calculated as a function of the financialexposure of nodes at a lower level of the hierarchical model linked tothe given counterparty-level node; and generating an aggregate financialexposure for the organization based on an aggregation of thecounterparty-level financial exposure.
 14. An article of manufactureaccording to claim 11, wherein aggregate financial exposure iscalculated using a payment netting method.
 15. An article of manufactureaccording to claim 11, wherein aggregate financial exposure iscalculated using a closeout setoff method.
 16. An article of manufactureaccording to claim 11, wherein aggregate financial exposure iscalculated using a margining method.
 17. An article of manufactureaccording to claim 11, wherein aggregate financial exposure iscalculated using a method using all possible netting and setoff.
 18. Anarticle of manufacture according to claim 11, further comprisingcalculating financial exposure for each master agreement in a masteragreement level.
 19. An article of manufacture according to claim 11,further comprising calculating financial exposure for each counterpartyin a counterparty level.
 20. An article of manufacture according toclaim 11, further comprising calculating financial exposure based onnetting, setoff, margin, and collateral requirements.
 21. A systemcomprising: means for creating a hierarchical model of legallyassociated counterparties and associated transactions with anorganization, wherein the hierarchical model includes one or morecounterparty levels containing the legally associated counterparties,and one or more master levels containing one or more master agreements,each master agreement being between one of the legally associatedcounterparties and the organization, and one or more transaction levelscontaining one or more transactions, wherein each master agreementprovides one or more mechanisms for financial aggregation of associatedtransactions between one or more of the counterparties and theorganization; and means for calculating aggregate financial exposure forthe organization at each level of the hierarchical model based on theone or more master agreements and their associated transactions.
 22. Asystem according to claim 21, wherein the hierarchical model furthercomprises: a root node representing a parent counterparty; one or morecounterparty levels in the hierarchical model structured by parent-childrelationships between one or more counterparties legally associated withthe parent counterparty, each counterparty of the one or morecounterparties being represented at a node of the counterparty levels,wherein one or more of the counterparty levels is linked to the rootnode; one or more master levels in the hierarchical model representingparent-child relationships between one or more agreements, wherein eachnode in the one or more master levels represents an agreement with oneor more of the one or more counterparties that provides one or moremechanisms for financial aggregation of transactions at a lower level inthe hierarchical model, and wherein one of the master levels is linkedto one of the counterparty levels; and a plurality of leaf nodes, eachrepresenting a transaction with the one or more of the one or morecounterparties, each leaf node of the plurality of leaf nodes beinglinked to one or more nodes of the one or more master levels or one ormore nodes of the one or more counterparty levels.
 23. A systemaccording to claim 21, wherein calculating aggregate financial exposureincludes: means for calculating transactional financial exposure at eachleaf node resulting from each of the one or more transactions; means forcalculating master-level financial exposure at each node of the one ormore master levels of the hierarchical model, wherein master-levelfinancial exposure at a given master-level node is calculated as afunction of the financial exposure of nodes at a lower level of thehierarchical model linked to the given master-level node; means forcalculating counterparty-level financial exposure at each node of theone or more counterparty levels of the hierarchical model, whereincounterparty-level financial exposure at a given counterparty-level nodeis calculated as a function of the financial exposure of nodes at alower level of the hierarchical model linked to the givencounterparty-level node; and means for generating an aggregate financialexposure for the organization based on an aggregation of thecounterparty-level financial exposure.
 24. A system according to claim21, wherein aggregate financial exposure is calculated using a paymentnetting method.
 25. A system according to claim 21, wherein aggregatefinancial exposure is calculated using a closeout setoff method.
 26. Asystem according to claim 21, wherein aggregate financial exposure iscalculated using a margining method.
 27. A system according to claim 21,wherein aggregate financial exposure is calculated using a method usingall possible netting and setoff.
 28. A system according to claim 21,further comprising means for calculating financial exposure for eachmaster agreement in a master agreement level.
 29. A system according toclaim 21, further comprising means for calculating financial exposurefor each counterparty in a counterparty level.
 30. A system according toclaim 21, further comprising means for calculating financial exposurebased on netting, setoff, margin, and collateral requirements.